\subsection{System architecture}
\label{sec:design_architecture}

\begin{figure}
\centering
\includegraphics[width=4in]{Images/architecture_practical.png}
%\includegraphics[width=0.75\textwidth]{Images/architecture_practical.png}
\caption{Architecture of a user-space approximation to a reference monitor, including event monitoring, recording, and support for cryptographic protection in user space}
\label{fig:architecture_practical}
\end{figure}

The difficulties in implementing a full SELinux module or the overhead of maintaining a specialized version of an existing module are beyond the scope of this project.  A proof of concept can be had entirely in user space and leveraging many existing tools.

Figure \ref{fig:architecture_practical} shows the overall design of our project.  It is implemented entirely in Linux user-space.  We have used two Linux facilities: $inotify$ and $audit$.  $inotify$ (inode notify) is a Linux kernel subsystem that provides hooks into user space for monitoring file system events and reporting these to applications.  $inotify$ can be used to monitor both directories and individual files.  

Linux $audit$ framework provides an auditing system that collects information about any security-relevant event.  $Audit$ maps processes to the user ID that started them, it provides tools to write audit reports and to filter these reports for certain events of interest.  Unauthorized users cannot remove the audit logs since they are owned by $root$.

The system operates in three phases.  First, $inotify$ signals our demon whenever a file of interest is modified.  Second, the $auditd$ daemon records who did the modification.  The audit log is parsed to determine this information.  The final step consists of writing this information as encrypted attributes back to the file system.  This is done by an encrypted tunnel layer.

Later, when the file is accessed again, this same tunnel is used to extract and validate the attributes.  Because these attributes are integrity protected, a user process can open a file anytime and check whether or not it can trust that file simply by calling a provided library interface.  This system obviously suffers the same name resolution vulnerabilities of any user-space process it hopes to protect.  While its operation is not actually secure, if we take the security of the framework itself to be transparent to the evaluation criteria, we can demonstrate a viable means to secure files from common name resolution attacks.

